home *** CD-ROM | disk | FTP | other *** search
- On Sun, 18 Apr 1993 23:10:39 -0400 (EDT), Laurence Lundblade wrote:
- > Would the functions just return plain unparsed strings? If so, then the
- > Resent-xxxx: cases would require the client to do address parsing. This
- > isn't a huge problem since the routines are there in the client anyway.
-
- Yes, just plain unparsed strings would be returned. I don't particularly
- understand why you would want to address-parse the ReSent-* strings (other
- than perhaps to canonicalize their format), but as you point out the routines
- you need are in c-client anyway.
-
- > It sounds like you have a choice of requesting the header lines that you
- > want, one at a time, or parsing a big string that comes back. The problem
- > with requesting the lines one at a time would be an RTT for each one,
- > right?
-
- Yes, that's correct. The real intent is to be able to gobble down the useful
- header lines in addition to what the envelope gives to you and possibly just
- blat them to the screen without any processing.
-
- > I'm also having trouble coming up with a use for the LINES.NOT function.
- > Did you have something in mind? That's not to say it should be take out.
-
- It's in there primarily for symmetry. I don't think Pine will need it, but
- I'm fairly confident that if I don't put it in now, someone will be nagging me
- for it later! :-) Also, it was a basic function in MM's header filters, so
- there is some precedent for its use.
-
- > I'm interested in the References: field for threading news groups and other
- > mail folders. I think you need it because the full tree of In-Reply-To:'s
- > might not be in the mailbox being threaded.
-
- I would be delighted if Pine solved the threading problem this way! ;-) Yes,
- enabling this sort of thing without having to go and change IMAP again was one
- of the motivations. It doesn't rescue me from someday having to deal with
- cross-post suppression in the .newsrc on the server case though. :-(
-
- -- Mark --
-
-
-
-